❯❯ 30 天交付承諾：公開 repo、可套用的流水線，和一場十一月要上場的婚禮

📍 流水線位置｜ 入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（今日：全線起點）

「這系統的後端，真的沒問題嗎？」

6 月 20 日發出第一個 Commit，4 個星期後，正式站正式上線。
整套系統包含 250 個 Commit、全數由單人完成開發。

翻開 Git log，伺服器上運行著 280 支端到端（E2E）測試，背後是全套 PostgreSQL 資料庫與 API 服務。然而上線那晚，相比於完成專案的成就感，心中更多的是對系統穩定度的疑慮：

「作為一名前端工程師，獨立建置後端架構與資料庫服務，這套由 AI 輔助產出的系統真的能穩定運作嗎？」

• 賓客名單
  

• 座位平面圖
  

• 謝卡公開頁
  

這套系統目前唯一的 VIP 使用者是我自己。
它不是 demo 用的玩具專案，而是今年 11 月要實際接住我自己婚禮的 婚禮 SaaS。

在工程開發中，需求可以重新協商、Iteration 可以延期；但婚期是無法延後（request extension）的絕對 Deadline。系統一旦在現場崩潰，影響的是真實的婚禮運作。

即使你目前沒有建置婚禮系統的需求，這套工程方法依然適用。
如果你在日常開發中也面臨類似情境：AI 生成程式碼的速度極快，但每次按下 merge 前卻缺乏對程式碼質量的把握，清楚它「跑得動」卻沒信心它「靠得住」。這 30 天的紀錄將提供一套可落地的解決方案。

重新分配「誰做什麼」：打造規格驅動流水線

• AI 負責：將定義明確的規格，精準且快速地轉譯為程式碼。
• 工程師負責：劃定守備範圍、設計自動化檢查機制（Gate）、決策技術架構與邊界條件。

AI 生成程式碼的速度極快，只要自動化驗證與約束閘門設計得夠嚴謹，前端工程師同樣具備交付穩定全端系統的能力。

這 30 天的拆解目標

工具更迭迅速，但 「規格驅動開發（SDD）與 CI/CD 護欄設計」 的架構邏輯不會過期。

本系列將完整拆解這條「一人 AI 規格流水線」：從需求輸入到自動部署，中間每一步均配置對應的自動化防範機制，防止 AI 與開發者的邏輯偏差。

以下 8 個階段，即為本系列的探索路線：

• 入口｜規格：將單一需求轉化為 AI 與開發者共同遵循的「規格合約」。
• flow｜資料流：拆解資料流與 API 邊界，在 AI 動手前先確立系統架構。
• 型別｜第一道護欄：利用型別系統約束合約，由編譯器先行攔截不符合規格的邏輯。
• mock｜假資料合約：在前後端解耦的前提下，透過 mock 確立介面規格，確保雙向開發不脫節。
• 測試｜煞車系統：E2E 測試作為防止線上事故的最後防線，解析測試全綠背後的隱含風險。
• UI｜介面接軌：在防護機制到位後對接 UI，維持高效率開發同時確保系統可控。
• vibe｜邊界放手：探討 vibe coding 的適用場景與安全邊界劃分。
• 上線｜自動部署：透過 CI/CD 整合流水線，將重複性驗證與部署交由自動化機制執行。

台灣人習慣把喜帖叫做紅色炸彈。而今年，我把這顆炸彈寄給了自己：發起人是我，開發是我，十一月要在婚禮現場承擔風險的還是我。一個不太寫後端的前端，就這樣被自己丟出了原本熟悉的那個圈。
但這系列不是為了展示我個人的開發紀錄，我希望這 30 天結束時，是讓你能夠帶走三樣東西：

1. 一個可直接 Clone 的模板 Repo（Nuxt4-template-SDD）
2. 一條可以根據你的專案大小自由裁剪的 AI 流水線
3. 一份真實記錄開發踩雷與修復過程的事故紀錄

明日預告：主流 AI 框架缺少的關鍵斷層

spec-kit、BMAD、OpenSpec、sdd.os 這些主流 AI 開發框架都很完整，
但為什麼一進到真實專案落地時，往往會卡在半路上？

明天（Day 02），我們就從這個被多數框架忽略的關鍵斷層聊起。

🗂 全系列目錄維護｜30 天文章總覽連結（開賽後逐日更新）
📎 本篇證據｜第一個 Commit：2026-06-20 scaffold・repo 連結